在敏捷軟體開發中，我想寫測試是一個被提倡的事，身為專業的軟體開發者，透過邊寫測試確保自己的程式符合預期是常見的手段。

而編寫測試在概念上，無非就是很簡單的三板斧：

1. 假定什麼情況
2. 在發生什麼事時
3. 預期會怎麼樣

如果與預期不合，測試程式就會報錯，開發者就能即時發現，進而查看原因，然後針對被測試的程式去調整。套用前面提及的三本柱，測試程式就是揭露了透明性，讓開發者能快速地檢視與調適。

而我認為目標與預測也是同樣的道理，這兩者其實都讓我們有某種預期，有了預期我就能即時了解到是否偏離了。

比如說，在 Scrum 的 Sprint Planning 時，團隊都會預測在該次 Sprint 能完成什麼。當我發現離這個預測開始偏離時，那就是該檢視與調整的時候了。可能是即時檢視團隊的開發狀況有發生什麼意外、或是該待辦項目有些範疇、工作量不在當初的預期內，接著就去調整團隊的開發方式，或即時找產品負責人（Product Owner）釐清與協調。

又或是當我以每個 Task 都應在 1 小時後往下一階段移動時，那是不是在使用到超過 1 小時後，我就開意識到情況不對勁，該進行檢視與調適。可能是發現需要的技術超出自己的能力，那我可能就要向團隊成員求救；可能是我這 1 小時太多干擾，我應該調整自己的工作環境。

另外舉一個比較貼近我們的，在鐵人賽時，我總會預期每篇文章應該要以不超過 20 分鐘的時間寫完，那當我發現離時間越近時，我應該就得在我寫文章的結構、內容、篇幅做出調整。（其實學生時期的考試也滿像這樣的情境，當答題時間越接近尾聲時，我們就會調整答題策略）

所以這些預期、預測、目標，都是讓我們有了一個檢視與調適的預警線，儘管我們承諾會致力於達成，但是當發生偏離時，我們更該注重是如何調整，藉此去做出策略的調整或是協商。